웹 보안 헤더: 콘텐츠 보안 정책(CSP)과 자바스크립트 실행

끊임없이 진화하는 웹 보안 환경에서 크로스 사이트 스크립팅(XSS) 공격과 같은 취약점으로부터 웹 애플리케이션을 보호하는 것은 매우 중요합니다. 여러분의 무기고에 있는 두 가지 강력한 도구는 콘텐츠 보안 정책(CSP)과 브라우저 내에서 자바스크립트가 실행되는 방식에 대한 철저한 이해입니다. 이 블로그 게시물에서는 CSP의 복잡성을 파헤치고, 자바스크립트 실행과의 관계를 탐구하며, 전 세계 개발자와 보안 전문가를 위한 실행 가능한 통찰력을 제공할 것입니다.

콘텐츠 보안 정책(CSP) 이해하기

콘텐츠 보안 정책(CSP)은 크로스 사이트 스크립팅(XSS) 및 기타 코드 주입 공격을 완화하는 데 도움이 되는 강력한 보안 표준입니다. 이는 브라우저가 특정 웹 페이지에 대해 로드할 수 있는 리소스를 제어할 수 있도록 함으로써 작동합니다. 웹사이트 콘텐츠에 대한 화이트리스트라고 생각하면 됩니다. CSP를 정의함으로써 본질적으로 브라우저에게 어떤 소스의 콘텐츠(스크립트, 스타일, 이미지, 글꼴 등)가 안전한 것으로 간주되는지와 그 출처를 알려주는 것입니다. 이는 HTTP 응답 헤더를 사용하여 달성됩니다.

CSP 작동 방식

CSP는 Content-Security-Policy라는 HTTP 응답 헤더를 통해 구현됩니다. 이 헤더에는 허용되는 소스를 지시하는 지시문 집합이 포함되어 있습니다. 다음은 몇 가지 주요 지시문과 그 기능입니다:

• default-src: 다른 모든 fetch 지시문에 대한 대체 지시문입니다. 더 구체적인 지시문이 제공되지 않으면 default-src가 허용되는 소스를 결정합니다. 예를 들어, default-src 'self';는 동일한 출처의 리소스를 허용합니다.
• script-src: 자바스크립트 코드에 허용되는 소스를 정의합니다. 이것은 자바스크립트 실행을 직접 제어하는 데 영향을 미치므로 가장 중요한 지시문이라고 할 수 있습니다.
• style-src: CSS 스타일시트에 허용되는 소스를 지정합니다.
• img-src: 이미지에 허용되는 소스를 제어합니다.
• font-src: 글꼴에 허용되는 소스를 정의합니다.
• connect-src: 연결(예: XMLHttpRequest, fetch, WebSocket)에 허용되는 소스를 지정합니다.
• media-src: 오디오 및 비디오에 허용되는 소스를 정의합니다.
• object-src: Flash와 같은 플러그인에 허용되는 소스를 지정합니다.
• frame-src: 프레임 및 iframe에 허용되는 소스를 정의합니다(사용 중단됨, child-src 사용).
• child-src: 웹 워커 및 포함된 프레임 콘텐츠에 허용되는 소스를 지정합니다.
• base-uri: 문서의 <base> 요소에 사용할 수 있는 URL을 제한합니다.
• form-action: 양식 제출에 유효한 엔드포인트를 지정합니다.
• frame-ancestors: 페이지가 포함될 수 있는 유효한 부모를 지정합니다(예: <frame> 또는 <iframe>).

각 지시문에는 소스 표현식 집합을 할당할 수 있습니다. 일반적인 소스 표현식은 다음과 같습니다:

• 'self': 동일한 출처(스키마, 호스트, 포트)의 리소스를 허용합니다.
• 'none': 모든 리소스를 차단합니다.
• 'unsafe-inline': 인라인 자바스크립트 및 CSS를 허용합니다. 이는 일반적으로 권장되지 않으며 가능한 한 피해야 합니다. CSP가 제공하는 보호 기능을 크게 약화시킵니다.
• 'unsafe-eval': eval()과 같이 XSS 공격에 자주 사용되는 함수의 사용을 허용합니다. 이 또한 매우 권장되지 않습니다.
• data:: 데이터 URL(예: base64로 인코딩된 이미지)을 허용합니다.
• blob:: blob: 스키마를 가진 리소스를 허용합니다.
• https://example.com: 지정된 도메인에서 HTTPS를 통해 리소스를 허용합니다. https://example.com/assets/와 같이 특정 경로를 지정할 수도 있습니다.
• *.example.com: example.com의 모든 하위 도메인에서 리소스를 허용합니다.

CSP 헤더 예시:

다음은 CSP 헤더가 어떻게 사용되는지를 보여주는 몇 가지 예시입니다:

예시 1: 자바스크립트를 동일한 출처로 제한하기

            Content-Security-Policy: script-src 'self';
            

              
                Copy
              
            
          

이 정책은 브라우저가 페이지와 동일한 출처에서만 자바스크립트를 실행하도록 허용합니다. 이는 외부 소스에서 주입된 모든 자바스크립트의 실행을 효과적으로 방지합니다. 이는 많은 웹사이트에 좋은 출발점입니다.

예시 2: 동일한 출처와 특정 CDN에서 자바스크립트 허용하기

            Content-Security-Policy: script-src 'self' cdn.example.com;
            

              
                Copy
              
            
          

이 정책은 동일한 출처와 cdn.example.com 도메인에서 자바스크립트를 허용합니다. 이는 CDN(콘텐츠 전송 네트워크)을 사용하여 자바스크립트 파일을 제공하는 웹사이트에서 일반적입니다.

예시 3: 스타일시트를 동일한 출처와 특정 CDN으로 제한하기

            Content-Security-Policy: style-src 'self' cdn.example.com;
            

              
                Copy
              
            
          

이 정책은 CSS 로딩을 원본 출처와 cdn.example.com으로 제한하여 다른 소스에서 악성 스타일시트가 로드되는 것을 방지합니다.

예시 4: 보다 포괄적인 정책

            Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com; style-src 'self' fonts.googleapis.com; img-src 'self' data:; font-src fonts.gstatic.com;
            

              
                Copy
              
            
          

이것은 동일한 출처의 콘텐츠, 동일한 출처 및 CDN의 자바스크립트, 동일한 출처 및 Google Fonts의 CSS, 동일한 출처 및 데이터 URL의 이미지, Google Fonts의 글꼴을 허용하는 더 복잡한 예입니다. 사이트에서 외부 리소스를 사용하는 경우 명시적으로 허용해야 한다는 점에 유의하십시오.

CSP 시행

CSP는 두 가지 주요 방법으로 시행될 수 있습니다:

• 보고 전용 모드(Report-Only Mode): Content-Security-Policy-Report-Only 헤더를 설정할 수 있습니다. 이 헤더는 리소스를 차단하지 않고 대신 지정된 엔드포인트(예: 사용자가 제어하는 서버)에 위반 사항을 보고합니다. 이는 CSP 정책을 시행하기 전에 테스트하여 잠재적인 문제를 식별하고 웹사이트가 손상되는 것을 방지하는 데 유용합니다. 브라우저는 여전히 리소스를 로드하려고 시도하지만 개발자 콘솔에 경고를 표시하고 지정된 엔드포인트로 보고서를 보냅니다. 보고서에는 차단된 리소스의 소스 및 위반 지시문과 같은 위반에 대한 세부 정보가 포함됩니다.
• 시행 모드(Enforce Mode): Content-Security-Policy 헤더를 사용하면 브라우저가 정책을 적극적으로 시행합니다. 리소스가 정책을 위반하는 경우(예: 승인되지 않은 소스에서 스크립트가 로드되는 경우) 브라우저는 이를 차단합니다. 이것이 보안을 위해 CSP를 사용하는 의도된 가장 효과적인 방법입니다.

자바스크립트 실행과 CSP

CSP와 자바스크립트 실행 간의 상호 작용은 매우 중요합니다. CSP의 script-src 지시문은 자바스크립트가 처리되는 방식에 대한 기본 제어 지점입니다. 브라우저가 자바스크립트를 만나면 CSP 헤더의 script-src 지시문을 확인합니다. 자바스크립트 소스가 허용되면 브라우저는 이를 실행합니다. 소스가 허용되지 않으면 스크립트가 차단되고 보고가 활성화된 경우 위반 보고서가 생성됩니다.

자바스크립트 실행에 미치는 영향

CSP는 자바스크립트 코드를 작성하고 구조화하는 방식에 상당한 영향을 미칩니다. 구체적으로 다음과 같은 영향을 미칠 수 있습니다:

• 인라인 자바스크립트: HTML의 <script> 태그 내에 직접 작성된 자바스크립트는 종종 제한됩니다. script-src에 'unsafe-inline'을 사용하면 이 제한이 완화되지만 강력히 권장되지 않습니다. 더 나은 접근 방식은 인라인 자바스크립트를 외부 자바스크립트 파일로 옮기는 것입니다.
• eval() 및 기타 동적 코드 실행: eval(), 문자열 인수가 있는 setTimeout(), new Function()과 같은 함수는 종종 제한됩니다. 'unsafe-eval' 소스 표현식을 사용할 수 있지만 피해야 합니다. 대신 이러한 관행을 피하도록 코드를 리팩터링하거나 대체 방법을 사용하십시오.
• 외부 자바스크립트 파일: CSP는 로드할 수 있는 외부 자바스크립트 파일을 제어합니다. 이는 악성 스크립트를 주입하려는 XSS 공격에 대한 주요 방어 수단입니다.
• 이벤트 핸들러: 인라인 이벤트 핸들러(예: <button onclick="myFunction()"></button>)는 'unsafe-inline'이 허용되지 않는 한 종종 차단됩니다. 자바스크립트 파일에서 이벤트 리스너를 첨부하는 것이 더 좋은 방법입니다.

CSP를 사용한 자바스크립트 실행 모범 사례

CSP를 효과적으로 사용하고 자바스크립트 실행을 보호하려면 다음 모범 사례를 고려하십시오:

• 인라인 자바스크립트 피하기: 모든 자바스크립트 코드를 외부 .js 파일로 옮기십시오. 이것이 여러분이 할 수 있는 가장 영향력 있는 단일 조치입니다.
• eval() 및 기타 동적 코드 실행 피하기: eval(), 문자열 인수가 있는 setTimeout(), new Function() 사용을 피하도록 코드를 리팩터링하십시오. 이것들은 일반적인 공격 벡터입니다.
• 필요한 경우 인라인 스크립트에 논스(Nonces) 또는 해시(Hashes) 사용: 반드시 인라인 스크립트를 사용해야 하는 경우(예: 레거시 코드의 경우), 논스(고유하고 무작위로 생성된 문자열) 또는 해시(스크립트 내용의 암호화 다이제스트) 사용을 고려하십시오. CSP 헤더와 스크립트 태그에 논스 또는 해시를 추가합니다. 이렇게 하면 브라우저는 지정된 기준과 일치하는 스크립트만 실행할 수 있습니다. 이는 'unsafe-inline'보다 더 안전한 대안이지만 복잡성이 추가됩니다.
• 엄격한 CSP 정책 활용: 제한적인 CSP 정책(예: script-src 'self';)으로 시작하여 필요에 따라 점차적으로 완화하십시오. 정책을 시행하기 전에 Content-Security-Policy-Report-Only 헤더를 사용하여 위반 사항을 모니터링하십시오.
• CSP 정책 정기적으로 검토 및 업데이트: 웹 애플리케이션은 시간이 지남에 따라 진화하며 CSP 정책도 마찬가지입니다. 정책이 계속해서 적절한 보호를 제공하는지 확인하기 위해 정기적으로 정책을 검토하고 업데이트하십시오. 여기에는 새로운 기능을 추가하거나, 서드파티 라이브러리를 통합하거나, CDN 구성을 변경할 때가 포함됩니다.
• 웹 애플리케이션 방화벽(WAF) 사용: WAF는 CSP를 우회할 수 있는 공격을 탐지하고 완화하는 데 도움이 될 수 있습니다. WAF는 추가적인 방어 계층 역할을 합니다.
• 설계 시 보안 고려: 프로젝트 시작부터 보안 코딩 관행 및 정기적인 보안 감사를 포함한 보안 원칙을 구현하십시오.

실제 적용 사례: 실제 예시

몇 가지 실제 시나리오와 CSP가 취약점을 완화하는 데 어떻게 도움이 되는지 살펴보겠습니다:

시나리오 1: 외부 소스로부터의 XSS 공격 방지

한 웹사이트에서 사용자가 댓글을 제출할 수 있도록 허용합니다. 공격자가 댓글에 악성 자바스크립트를 주입합니다. CSP가 없으면 브라우저는 주입된 스크립트를 실행합니다. 동일한 출처의 스크립트만 허용하는 CSP(script-src 'self';)를 사용하면 브라우저는 다른 소스에서 발생했기 때문에 악성 스크립트를 차단합니다.

시나리오 2: 신뢰할 수 있는 CDN 침해로 인한 XSS 공격 방지

한 웹사이트에서 CDN(콘텐츠 전송 네트워크)을 사용하여 자바스크립트 파일을 제공합니다. 공격자가 CDN을 손상시키고 합법적인 자바스크립트 파일을 악성 파일로 교체합니다. CDN의 도메인을 지정하는 CSP(예: script-src 'self' cdn.example.com;)를 사용하면 웹사이트는 특정 CDN 도메인에서 호스팅되는 파일로만 실행을 제한하기 때문에 보호됩니다. 손상된 CDN이 다른 도메인을 사용하는 경우 브라우저는 악성 스크립트를 차단합니다.

시나리오 3: 서드파티 라이브러리로 인한 위험 완화

한 웹사이트가 서드파티 자바스크립트 라이브러리를 통합합니다. 해당 라이브러리가 손상되면 공격자는 악성 코드를 주입할 수 있습니다. 엄격한 CSP를 사용하여 개발자는 CSP 정책에서 소스 지시문을 지정하여 서드파티 라이브러리의 자바스크립트 실행을 제한할 수 있습니다. 예를 들어, 서드파티 라이브러리의 특정 출처를 지정함으로써 웹사이트는 잠재적인 악용으로부터 자신을 보호할 수 있습니다. 이는 전 세계적으로 많은 프로젝트에서 자주 사용되는 오픈 소스 라이브러리의 경우 특히 중요합니다.

글로벌 예시:

전 세계의 다양한 디지털 환경을 고려해 봅시다. 인구가 많고 인터넷 보급률이 높은 인도와 같은 국가는 연결된 장치의 수가 증가함에 따라 고유한 보안 문제에 직면하는 경우가 많습니다. 마찬가지로, 엄격한 GDPR(일반 데이터 보호 규정) 준수가 요구되는 유럽과 같은 지역에서는 안전한 웹 애플리케이션 개발이 가장 중요합니다. CSP를 사용하고 안전한 자바스크립트 관행을 채택하면 이 모든 지역의 조직이 보안 규정 준수 의무를 충족하는 데 도움이 될 수 있습니다. 전자상거래가 빠르게 성장하고 있는 브라질과 같은 국가에서는 비즈니스와 소비자 모두를 보호하기 위해 CSP로 온라인 거래를 보호하는 것이 중요합니다. 이는 나이지리아, 인도네시아 및 모든 국가에서도 마찬가지입니다.

고급 CSP 기법

기본 사항 외에도 CSP 구현을 향상시킬 수 있는 몇 가지 고급 기법이 있습니다:

• 논스 기반 CSP: 인라인 스크립트로 작업할 때 논스는 'unsafe-inline'보다 더 안전한 대안을 제공합니다. 논스는 각 요청에 대해 생성하고 CSP 헤더(script-src 'nonce-YOUR_NONCE';)와 <script> 태그(<script nonce="YOUR_NONCE">) 모두에 포함하는 고유하고 무작위로 생성된 문자열입니다. 이렇게 하면 브라우저에 일치하는 논스가 있는 스크립트만 실행하도록 지시합니다. 이 접근 방식은 공격자가 악성 코드를 주입할 가능성을 크게 제한합니다.
• 해시 기반 CSP (SRI - 하위 리소스 무결성): 이를 통해 스크립트 콘텐츠의 암호화 해시(예: SHA-256 알고리즘 사용)를 지정할 수 있습니다. 브라우저는 해시가 CSP 헤더의 해시와 일치하는 경우에만 스크립트를 실행합니다. 이것은 인라인 스크립트(덜 일반적임) 또는 외부 스크립트를 처리하는 또 다른 방법입니다. 하위 리소스 무결성은 일반적으로 CSS 및 자바스크립트 라이브러리와 같은 외부 리소스에 사용되며, 의도된 라이브러리와 다른 악성 코드를 제공하는 손상된 CDN의 위험으로부터 보호합니다.
• CSP 보고 API: CSP 보고 API를 사용하면 위반 지시문, 차단된 리소스의 소스 및 위반이 발생한 페이지의 URL을 포함하여 CSP 위반에 대한 자세한 정보를 수집할 수 있습니다. 이 정보는 CSP 정책을 모니터링, 문제 해결 및 개선하는 데 필수적입니다. 여러 도구와 서비스가 이러한 보고서를 처리하는 데 도움이 될 수 있습니다.
• CSP 빌더 도구: CSP 평가기 및 온라인 CSP 빌더와 같은 도구는 CSP 정책을 생성하고 테스트하는 데 도움이 될 수 있습니다. 이를 통해 정책 생성 및 관리 프로세스를 간소화할 수 있습니다.

자바스크립트 실행 및 보안 모범 사례

CSP 외에도 자바스크립트와 관련된 다음과 같은 일반적인 보안 모범 사례를 고려하십시오:

• 입력 유효성 검사 및 살균(Sanitization): XSS 및 기타 주입 공격을 방지하기 위해 항상 서버 측과 클라이언트 측에서 사용자 입력을 유효성 검사하고 살균하십시오. 스크립트를 시작하는 데 사용되는 문자와 같이 잠재적으로 위험한 문자를 제거하거나 인코딩하도록 데이터를 살균하십시오.
• 안전한 코딩 관행: SQL 주입을 방지하기 위해 매개변수화된 쿼리를 사용하는 것과 같은 안전한 코딩 원칙을 따르고, 클라이언트 측 코드에 민감한 데이터를 저장하지 마십시오. 코드가 잠재적으로 민감한 데이터를 처리하는 방식에 유의하십시오.
• 정기적인 보안 감사: 모의 해킹을 포함한 정기적인 보안 감사를 실시하여 웹 애플리케이션의 취약점을 식별하고 해결하십시오. 모의 해킹이라고도 하는 보안 감사는 시스템에 대한 시뮬레이션 공격입니다. 이러한 감사는 공격자가 악용할 수 있는 취약점을 탐지하는 데 필수적입니다.
• 종속성 최신 상태 유지: 알려진 취약점을 패치하기 위해 자바스크립트 라이브러리 및 프레임워크를 정기적으로 최신 버전으로 업데이트하십시오. 취약한 라이브러리는 보안 문제의 주요 원인입니다. 종속성 관리 도구를 사용하여 업데이트를 자동화하십시오.
• HTTP Strict Transport Security(HSTS) 구현: 웹 애플리케이션이 HTTPS를 사용하고 HSTS를 구현하여 브라우저가 항상 HTTPS를 통해 사이트에 연결하도록 강제하는지 확인하십시오. 이는 중간자 공격을 방지하는 데 도움이 됩니다.
• 웹 애플리케이션 방화벽(WAF) 사용: WAF는 악성 트래픽을 필터링하고 다른 보안 조치를 우회하는 공격을 방지하여 추가적인 보안 계층을 추가합니다. WAF는 SQL 주입 또는 XSS 시도와 같은 악성 요청을 탐지하고 완화할 수 있습니다.
• 개발팀 교육: 개발팀이 CSP, XSS 방지 및 안전한 코딩 원칙을 포함한 웹 보안 모범 사례를 이해하도록 하십시오. 팀 교육은 보안에 대한 중요한 투자입니다.
• 보안 위협 모니터링: 보안 사고를 신속하게 탐지하고 대응하기 위해 모니터링 및 경고 시스템을 설정하십시오. 효과적인 모니터링은 잠재적인 보안 위협을 식별하고 대응하는 데 도움이 됩니다.

종합: 실용 가이드

이러한 개념을 적용하는 방법을 설명하기 위해 간단한 예제를 만들어 보겠습니다.

시나리오: 자바스크립트를 사용하여 양식 제출을 처리하는 간단한 연락처 양식이 있는 웹사이트.

1. 1단계: 애플리케이션의 종속성 분석: 애플리케이션이 사용하는 모든 자바스크립트 파일, 외부 리소스(CDN 등) 및 인라인 스크립트를 파악합니다. 적절한 기능에 필요한 모든 스크립트를 식별합니다.
2. 2단계: 자바스크립트를 외부 파일로 이동: 모든 인라인 자바스크립트를 별도의 .js 파일로 옮깁니다. 이것은 기본입니다.
3. 3단계: 기본 CSP 헤더 정의: 제한적인 CSP로 시작합니다. 예를 들어, 동일한 출처를 사용하는 경우 다음과 같이 시작할 수 있습니다:

               Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:;
               
   
                 
                   Copy
                 
               
             

4. 4단계: 보고 전용 모드에서 CSP 테스트: 잠재적인 충돌을 식별하기 위해 처음에 Content-Security-Policy-Report-Only 헤더를 구현합니다. 보고서를 수집하고 분석합니다.
5. 5단계: 모든 위반 사항 해결: 보고서를 기반으로 필요한 리소스를 허용하도록 CSP 헤더를 조정합니다. 여기에는 특정 CDN 도메인을 화이트리스트에 추가하거나, 절대적으로 필요한 경우 인라인 스크립트에 논스나 해시를 사용하는 것이 포함될 수 있습니다(모범 사례를 따르면 거의 필요하지 않음).
6. 6단계: 배포 및 모니터링: CSP가 올바르게 작동한다고 확신하면 Content-Security-Policy 헤더로 전환합니다. 애플리케이션의 위반 사항을 지속적으로 모니터링하고 필요에 따라 CSP 정책을 조정합니다.
7. 7단계: 입력 유효성 검사 및 살균 구현: 취약점을 방지하기 위해 서버 측 및 클라이언트 측 코드가 사용자 입력을 유효성 검사하고 살균하는지 확인합니다. 이는 XSS 공격으로부터 보호하는 데 중요합니다.
8. 8단계: 정기적인 감사 및 업데이트: 새로운 기능, 통합 및 애플리케이션 아키텍처 또는 의존하는 종속성의 변경 사항을 염두에 두고 CSP 정책을 정기적으로 검토하고 업데이트합니다. 예상치 못한 문제를 발견하기 위해 정기적인 보안 감사를 구현합니다.

결론

콘텐츠 보안 정책(CSP)은 현대 웹 보안의 핵심 구성 요소로, 자바스크립트 실행 관행과 함께 작동하여 광범위한 위협으로부터 웹 애플리케이션을 보호합니다. CSP 지시문이 자바스크립트 실행을 제어하는 방식을 이해하고 보안 모범 사례를 준수함으로써 XSS 공격의 위험을 크게 줄이고 웹 애플리케이션의 전반적인 보안을 강화할 수 있습니다. CSP를 입력 유효성 검사, 웹 애플리케이션 방화벽(WAF) 및 정기적인 보안 감사와 같은 다른 보안 조치와 통합하여 계층화된 보안 접근 방식을 채택하는 것을 기억하십시오. 이러한 원칙을 지속적으로 적용함으로써 사용자의 위치나 사용하는 기술에 관계없이 더 안전하고 보안이 강화된 웹 경험을 만들 수 있습니다. 웹 애플리케이션을 보호하는 것은 데이터를 보호할 뿐만 아니라 전 세계 잠재 고객과의 신뢰를 구축하고 신뢰성과 보안에 대한 명성을 쌓는 것입니다.